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REMARKS 

Status of this application 

In the Office Action mailed on February 23, 2003, claims 1 and 12 (and their dependent 
claims 2-7 and 13-18 respectively) were rejected as being indefinite due to an insufficient 
antecedent basis for some of the terms. 

Claims 1-5 and 8-16 were rejected under 35 U.S.C. § 102(e) as being anticipated by 
Meltzer et al. Patent 6,542,912 (hereinafter "Meltzer"). Claims 6-7 and 17-18 were rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Meltzer in view of Walker et al. Patent 
6,041,308 (hereinafter "Walker"). 

The Office Action Summary indicated that the Action was "Responsive to the 
communication filed on 31 May 2000" (the application as filed) but does not acknowledge 
receipt and entry of the Preliminary Amendment which applicants filed for this application on 
April 10, 2003. In the event that Preliminary Amendment was not received and entered, the 
Examiner is requested to call applicants* undersigned attorney at (508) 778-2630. 

This response amends the three independent claims 1, 8 and 12 to correct the points of 
indefiniteness noted by the Examiner and to more clearly distinguish applicants' invention from 
the system described in Meltzer. This response requests reconsideration of the outstanding 
rejection based on the prior art for the reasons set forth below. 

Applicants^ Invention 

The present invention provide methods and apparatus that pemiit executing application 
programs to obtain and process information obtained via the Internet from identified remote 
resources. A service interface program accepts a ser\'ice request identifying a particular 
resource fi-om an executing application program. A service interface program is then executed in 
response to each such service request to obtain the particular service description corresponding 
to the identified resoxirce Irom a services registry. The interface program then transmits an 
output information request to the address specified in the fetched service description, supplies 
input information fi-om the executing application program in a format meeting the specification 
contained in said particular service description to the resource, and returns output information 
provided by the resource to the requesting application program. 
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The Meltzer system for executing commercial transactions also uses a database which 
stores service descriptions that specify the nature of the input and output information handled by 
a service by defining XML input and output documents. When an incoming XML document is 
parsed by the service provider and its document type is identified, the document type is used by 
the service provider to identify and invoke a transaction process for translating the incoming 
XML document into suitable form for transaction processing, performs the processing associated 
with that document type, and then translates the processing results into an XML response 
document that is returned to the sender. The Meltzer system uses the service description 
information stored in the database to publish the manner in which the service provider performs 
transaction processing in response to defined input XML docimients to yield defined XML 
output documents. Meltzer also uses the service descriptions to create the translation programs 
needed to process an incoming XML document (see Fig. 9). 

Meltzer' s system is not used to dynaniically respond to a request from an executing 
application program by consulting a service description database to determine the nature of the 
input information needed, translate that information into the format specified by the service 
description, transmit the input information to an Internet address specified in the service 
description, and then return the output information returned by the service provider to the 
requesting executing application program. 

Unlike applicants' invention as claimed, Meltzer does not provide an application program 
interface whose services may be invoked by an executing application program in order to trigger 
a service description lookup operation to determine how the application program's service 
request should be handled. In the Meltzer system, services are requested by transmitting an input 
XML docimient to the service provider which invokes transaction processing by determining the 
type of docimient received. Meltzer does not respond to a service request firom an application 
program by performing a service description lookup operation and then processing the 
application program's request in accordance with the service description. 

In rejecting claims 1 and 12, the Examiner cited column 19, lines 16-40 as being a 
teaching of a mechanism for issuing a service request and then executing a service interface 
program in response to the request. However, the cited passage of Meltzer describes the 
mechanism shown in Fig. 9 in which Meltzer's **BIC Builder" facility is used to accept 
information fi-om a participant which defines a service in a standard way that may be used to set 
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up the host processing facilities and that is then pubhshed. The mechanism described in Fig. 9 
the cited passage does perfomi service description lookups in order to handle service requests. 

The Examiner further cites Meltzer at column 24, line 56 to column 25, line 5 for a 
teaching of transmitting an information request specified in a service description. This cited 
passage explains the manner in which a host service provider processes an incoming input XML 
document by parsing it, translating its content into a form suitable for processing, and then 
routing that data to a transaction routine which is determined by the document type of the input 
XML document. There is no suggestion anywhere in this passage that an interface routine is 
used to dynamically determine the Intemet address to which a request is sent firom a service 
description in response to a request from an executing application program as claimed. The 
Examiner further relied upon this passage in the rejection of claim 8 as being a teaching of 
retrieving a service description for a specified resource from the database. As noted above, this 
passage is concerned solely with the routing of an incoming XML document to a particular 
handling routing based on its document type, an operation which does not include consulting the 
service description database. 

Independent claims 1, 8 and 12 have been amended to more clearly define and 
particularly set forth the novel features of applicants* invention. As amended, claims 1, 8 and 12 
are believed to even more clearly distinguish applicants' invention from Meltzer and all claims 
are accordingly believed to be allowable. 

With respect to the rejection for obvioxisness, it is submitted that there is nothing in either 
Meltzer or Walker that would suggest that a service description might advantageously include 
test input signal values and result values which should be created by a correctly functioning 
invoked service, or that the service description might advantageously include security 
information to ensure that an service request originates from an authorized source. Since there is 
no suggestion in either reference of the subject matter of claims 6-7 and 17-18, it is believed that 
the rejection based on the combination of these references is improper and should be withdrawn. 

Reconsideration and allowance of claims 1-18 as amended is requested. 



9 

. .PACE 10/13- RCVDAT 6^3/2004 11:29:51 PM [Eastern Daylight Timel • SVR:USPTO-EPXRP.1/0* DNIS: 87293 08 • CSID: 50 8 778 2630 • DURATION (mm-ss):05^0 



Dated: June 23, 20O4 




Jun 23 2004 10:23PM CHRRLES G CALL 



(508) 778-2G30 



p- 1 1 



Certificate of Transmission under 37 CFR 1.8 



I hereby certify that this Amendment is being transmitted by facsimile to the central 
facsimile number of the U.S. Patent and Trademarkj3f?Mke^f703^ 872=9^06, on June 23, 2004. 



Dated: June, 23 2004 



Signature 




Charles G. Call» Reg, 
USPTO Customer No. 021253 
68 Horse Pond Road 
West Yarmouth, MA 02673 
Ph. (508) 778-2630 Fax (508) 629-6540 
call@patentsoft.com 
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